Communication networks typically operate in accordance with a given standard or specification which sets out what the elements of the network are permitted to do and how that should be achieved. The communication in the networks typically follows predefined rules which are referred to in the following as protocols. The protocols to be used are defined in the associated standards or specifications. The protocols can be used for transmission of necessary control information between the various network elements.
A communication network is a cellular radio network consisting of access entities referred to as cells. In most cases the cell consists of a certain radio access area covered by one or several base transceiver stations (BTS) serving mobile stations (MS) via a radio interface and connected to a base station subsystem (BSS). Several cells cover a larger area, and form the coverage area of a cellular radio network. The cell (or group of cells) and thus the mobile station (MS) (that is sometimes referred to as user equipment UE) within one of the cells of the system can be controlled by a node providing control function. An example of such controller is a radio network controller (RNC) of a universal mobile telecommunication system (UMTS) terrestrial radio access network (UTRAN). The RNC controls the communication between the base station and the mobile station based on predefined protocols, such as Radio Resource Control (RRC) or Medium Access Control (MAC) or Radio Link Control (RLC) protocols. An example of a controller node implemented in the core network (CN) side of the cellular network is a mobile switching center (MSC).
For example, in the 3rd generation UMTS a RNC can be connected further to a serving GPRS support node (SGSN) which in turn is connected to a gateway or linking node, for example a gateway GPRS support node (GGSN) or gateway mobile switching center (GMSC), linking the cell to the other parts of the communication system and/or other communication networks, such as to a PSTN (Public Switched Telecommunications Network) or to a data network, such as to a X.25 based network or to an IP (Internet Protocol) based network.
The wireless interface between the mobile station MS and the base station is typically controlled by only one access network controller at time. However, the MS may also be simultaneously controlled by several controller nodes. This may occur e.g. when the cells overlap or in so called soft handoff mode, where the MS may be in communication with two base stations which may be connected to different controllers, or when one controller is controlling another controller controlling the MS. One controller of the plurality of controllers in the system can be defined as a serving (main) controller whereas the others may act as drift i.e. secondary controllers.
The responsibility of controlling a connection between the mobile station and the network may change during an ongoing connection. It is therefore necessary to relocate at least part of the control functions associated with the connection from one controller to another such that the connection will not become disconnected an/or that the quality of the connection remains in an acceptable level. When relocation is decided to be performed, the serving controller or another node of the communication system may initiate the necessary proceeding for the relocation. The relocation of the control function can be refereed to as handover.
For example, in the current third generation partnership project (3GPP) Specifications it is defined that the core network (CN) can request the UTRAN to change the used ciphering and/or integrity protection keys for the air interface. This security procedure is initialised when the core network sends a radio access network application part (RANAP) message ‘SECURITY MODE COMMAND’ to the UTRAN. Based on this message the UTRAN, and more particularly, the access network controller thereof shall initialise the corresponding security procedure for the air interface. From the CN point of view this security procedure has been completed when the CN receives the RANAP message ‘SECURITY MODE COMPLETE’ from the UTRAN. Based on this information the CN can be sure that either the new ciphering key has been taken into use for the air interface or the mobile station has rejected the request for ciphering key change. The core network controller will also conclude from the acknowledgement message that the procedure has been terminated at the UTRAN side.
In the presently proposed arrangements the current i.e. ongoing security procedure assumes that the earlier initialised security procedure has already been terminated when the serving RNC requests the core network controller to perform a serving radio network subsystem (SRNS) relocation, i.e. handover between two access network controllers. However, the inventors have found that this may not always be the case. For example, it is possible that the security procedure is not completed if the defined activation time for the key change was originally defined to be a far a way from the current radio link controller sequence number (RLC SN) position. That is, the UTRAN keeps on operating with the “old” key until the timer functions indicates that it is time to change the key. In addition, since the reset procedures in the radio link controller (RLC) will start the transmission of frames from the beginning (from frame No. 0), sequentially occurring RLC reset procedures may have continuously postponed the elapsing of the new ciphering key activation time. The reset procedures is initiated e.g. when the connection quality is found to become poor. Thus it is possible that the mobile station has already acknowledged the ciphering key exchange by sending the RRC acknowledgement message ‘SECURITY MODE COMPLETE’ to the UTRAN (and which message the UTRAN has subsequently received) and that the new key activation time has not yet elapsed at the mobile station at the time when the serving radio network subsystem relocation procedure is initialised. This is a problem since it may lead into situation where the mobile station and the new or target radio access network controller have different ciphering keys. It is then possible that the relocation procedure fails as the mobile station and the new radio access network are not able to understand each other.
For example, the current RANAP message ‘RELOCATION REQUIRED’ contains the currently used ciphering key on the air interface inside a “IE: ciphering” key field. This field does not enable the serving RNC to indicate to the target RNC that the earlier generated security procedure was not terminated before the SRNS relocation procedure was started. The inventors have realised that the serving RNC should be able to transmit to the target RNC also that ciphering key which was already agreed with the mobile station in addition to the currently used (i.e. the “old”) ciphering key. This feature is, however, not supported in e.g. the current third generation specifications. The current security modes may not be able to handle properly a situation where the new ciphering key has not yet been taken into a use due to “late” activation time and the serving controller is forced to initialise a relocation procedure. This may happen e.g. if the RRC message ‘SECURITY MODE COMPLETE’ has been received by the SRNC before the initialisation of the SRNS relocation and before the activation timer at the mobile station has elapsed, i.e. while the mobile station and the currently serving RNC are still using the “old” key. The